1. Field of the Invention
The present invention relates to a packet transmitting method for transmitting and receiving packets among a plurality of data terminals, and a relaying device and a data terminal used for the packet transmission.
2. Description of Related Art
Recently, a demand for transmitting through the Internet such data as video data or audio data, which requires a real time transmission, has been intensified.
As a protocol to meet the demand, an RTP (Real time Transport Protocol) is ruled by the RFC (Request For Comment) 1889, which was issued by the IETF (Internet Engineering Task Force), a group for standardizing the Internet. The RTP has functions such as 1) specification of a payload type, 2) designation of a sequence number, and 3) designation of a timestamp. These rules enable such information as audio and video data to be transmitted in real time on the Internet. Usually, the RTP is used as an upper layer for the IP (internet protocol) on a network layer and the UDP (User Datagram Protocol) on a transport layer.
FIG. 13A shows contents of an RTP header, UDP header, and IP header (hereafter, referred to as “RTP/UDP/IP headers”) attached to data, such as audio and video data, to be transmitted according to the RTP, UDP and IP. Hereinafter, a packet including the RTP/UDP/IP headers is called an IP packet.
As shown in the drawing, the IP header needs 20 bytes, the UDP header needs 8 bytes, and the RTP header needs 12 bytes, thus the total amount of RTP/UDP/IP headers reaches 40 bytes. In contrast, video data contained in one IP packet comprises, for example, about 50 bytes. For transmitting such image data in the form of packets, the overhead reaches therefore no less than 44 percent. Similarly, for transmitting audio data which comprises 20 bytes in one packet, the overhead reaches as much as 66 percent. Since a practical transmission needs headers for other layers to be added, the whole headers occupy a large percentage of one packet, thereby causing a drawback of reducing efficiency in communication.
As one technique to overcome the drawback, the RFC2508 issued by the IETF shows an RTP compression protocol to compress the RTP/UDP/IP headers. The RTP compression protocol permits the RTP/UDP/IP headers shown in the FIG. 13A to be compressed into a header exemplified in FIG. 13B (hereinafter referred to as a “compressed header”). This compression will be detailed as follows.
The method of the compression is applied between two nodes on a network through which packets are transmitted among a plurality of data terminals, for example. More specifically, of the two nodes, one node (hereinafter referred to as a “sender node”) converts the RTP/UDP/IP headers of one part of the IP packets communicated among the data terminals into a compressed header, and transmits it, as a header-compressed packet, to the other node (hereinafter referred to as a “receiver node”). Concurrently, the sender node transmits the RTP/UDP/IP headers of the other part of the IP packets to the receiver node, as a full-header packet without any compression. The receiver node decompresses (i.e., restoration) to an IP packet the header-compressed packet or the full-header packet received from the sender node, and sends it to the next node or a receiver data terminal. The full header is a header in which lengths included in the RTP/UDP/IP headers shown in FIG. 13A are replaced by information including a CONTEXT_ID for identifying the RTP connection and a link sequence number link_seq, a serial number, given in the order of transmission from the sender node.
The content of the compressed header shown in FIG. 13B will now be explained. The data of sections with dense hatching applied in the RTP/UDP/IP headers in FIG. 13A, which includes a version number (V) written in the IP header and the payload type written in the RTP header, are constant data (hereinafter referred to as “static fields”) for each packet to be transmitted from the sender node. Hence, as illustrated in FIG. 13B, the compressed header does not include data of the static fields. When the sender node sends the first IP packet of the packet stream to the receiver node, it sends a full-header packet which has a full header including the static fields. After this, the sender node converts the RTP/UDP/IP headers of the succeeding IP packets into a compressed header with no static fields included. The thus-converted compressed header is sent to the receiver node as a header-compressed packet. When the receiver node receives the full header packet corresponding to the first IP packet, the receiver node restores the received RTP/UDP/IP headers with reference to the full header in the first received full-header packet, and writes the thus decompressed headers into an internal storage device. After this, the receiver node uses the static fields of the RTP/UDP/IP headers so as to restore the static fields of the compressed header in the header-compressed packets that will be received successively after the first packet.
The data in the static fields are not always constant over all the IP packets, but might be changed depending on a certain IP packet. If such a change occurs in a certain IP packet, the sender node will transmit a full header packet including a full header corresponding to the RTP/UDP/IP header of the IP packet to the receiver node, without compression.
The data in the sections with no hatching applied in the RTP/UDP/IP headers shown in FIG. 13A include the sequence number and timestamp of the RTP header as well as the ID of the IP header. The timestamp indicates the time at which a packet is transmitted or generated. Such data are expected to have constant difference values (changed amounts) between successive two IP packets transmitted in turn. Hereinafter, fields providing such data are referred to as “delta fields.” As shown in FIG. 13B, the basic compressed header does not include the data in the delta fields. As described above, the receiver node, which holds RTP/UDP/IP headers in its storage device, adds difference values, which have been previously obtained, respectively to the values in the corresponding delta fields of the stored RTP/UDP/IP headers, thus being able to decompress delta fields of compressed headers which will consecutively be received thereafter.
However, it is not always true that the difference values in the delta fields are constant between all the IP packets. There are some cases where changes are made to their difference values. In such cases, changed difference values have to be notified to the receiver node. The receiver node is able to restore the contents in the delta fields contained in the RTP/UDP/IP headers of each header-compressed packet which will be received thereafter, with reference to the contents of the RTP/UDP/IP headers held in the storage device and the newly notified difference values. For this purpose, the compressed header shown in FIG. 13A has flags S, T and I that represent whether the difference values in the delta fields are changed or not. If any difference values are changed, the new difference values are added to the compressed header, as shown by the dotted lines in FIG. 13B. Practically, if there is a change in the difference value of the sequence number of the RTP header, “1” is set to the flag S and a sequence number difference value (delta RTP sequence) showing the new difference value of the sequence number is added to the compressed header, as shown by the dotted line in FIG. 13B. Similarly, if there is a change in the difference value of the timestamp of the RTP header, “1” is set to the flag T, and a timestamp difference value (delta RTP timestamp) showing the new difference value of the timestamp is included in the compressed header, as shown by the dotted line in FIG. 13B. Further, if there is a change in the difference value of the ID of the IP header, “1” is set to the flag I, and an ID difference value (delta IP ID) showing the new difference value of the ID is attached to the compressed header.
As shown in FIG. 13B, the compressed header further includes the CONTEXT_ID and link_seq, like the full header. The receiver node decompresses the compressed header in compliance with the contents of RTP/UDP/IP headers specified by the CONTEXT_ID. The receiver node refers to the link sequence number link_seq of each packet (header-compressed packet or full-header packet) sent in order from the sender node. When it is found that some link sequence numbers are dropped, the receiver node determines that the packets are lost between the transmitter and receiver nodes.
Referring to FIG. 14, procedures made for packet transmission between the transmitter and receiver nodes will now be described. In FIG. 14, a field A shows a static field of the RTP/UDP/IP headers (i.e., any of the data with the dense hatching applied in FIG. 13A), and a field B shows a delta field (i.e., any of the data with no hatching applied in FIG. 13A). Further, in FIG. 14, “F” represents a full-header packet, while “C” represents a header-compressed packet.
When receiving an IP packet a transmitted from a transmitter data terminal to a receiver data terminal, the sender node stores the RTP/UDP/IP headers of the IP packet a into its internal storage device. Concurrently, the sender node produces a full header by substituting lengths in the headers for a CONTEXT_ID and link sequence number link_seq, and transmits to the receiver node the full header packet including both the produced full header and data (hereinafter referred to as an “RTP payload”), which is the part of the IP packet excluding the RTP/UDP/IP headers (refer to “OP1” in FIG. 14). The receiver node which received this full-header packet restores the RTP/UDP/IP headers from the full header of this packet (namely, the CONTEXT_ID and link_seq are extracted from the full header), and transmits the IP packet with this header to the next node or a receiver data terminal. In this operation, the decompressed RTP/UDP/IP headers are stored into its internal storage device.
The sender node then converts the RTP/UDP/IP headers in an IP packet b received after the IP packet a into a compressed header, and transmits the packet b with the compressed header to the receiver node (refer to “OP2” in FIG. 14). In the compressed header in the header-compressed packet, a difference value ΔB(=1) between a value [1] in the delta fields B of the packet b and a value [0] in the delta fields B of the last packet a is added, while a value of “1” is set to the flags (flags S, T and I shown in FIG. 13B) that represent changes or non-changes in the difference value.
The receiver node, which received the header-compressed packet b, obtains the delta fields B of the compressed headers of the header-compressed packet b by adding the difference value ΔB notified in this packet to the values of the delta fields B of the RTP/UDP/IP headers of the last IP packet a stored in the internal storage. The receiver node then transmits an IP packet b having both of the RTP/UDP/IP headers, which include the delta fields B and the static fields A of the RTP/UDP/IP headers of the IP packet a, and the RTP payload. The RTP/UDP/IP headers referred in decompressing the IP packet b (in this case, the RTP/UDP/IP headers extracted from the last IP packet a) is specified by the CONTEXT_ID of the header-compressed packet b. The RTP/UDP/IP headers of the IP packet b and the difference value ΔB notified in this packet are also stored in the internal storage.
When next receiving an IP packet c, the sender node calculates a difference value between values of delta fields B of both of the IP packet c and the last IP packet b. The difference value ΔB is [1] (=3−2) in this case, which is the same as the previous one notified to the receiver node last time. Therefore, there is no need to newly notify the receiver node of the unchanged difference value. Hence, the sender node transmits to the receiver node a header-compressed packet c having a compressed header with no difference value (i.e., information shown by the dotted line in FIG. 13B (refer to “OP3” in FIG. 14). The receiver node that received this header-compressed packet c adds the stored difference value ΔB to the delta fields B of the previous packet b, thereby decompressing the delta fields B of this compressed header of the header-compressed packet. Then the receiver node sends an IP packet c composed of both RTP/UDP/IP headers, including the decompressed value and the static fields A extracted from the full header of the full-header packet a, and RTP payload. The next packet d is processed similarly.
The delta fields B of an IP packet e next received by the sender node is [5] in value, of which difference value from the delta fields B of the last IP packet d is [2]. When the difference value ΔB is changed in this way, the sender node transmits a header-compressed packet e having a compressed header in which the changed new difference value is added and the corresponding flag is set to [1]. The receiver node adds the newly notified difference value to the values of the delta fields B of the IP packet d so as to decompress the delta fields B of the packet e, then transmits an IP packet containing the decompressed delta fields B.
The sender node then receives an IP packet g, which is different in the static field A from the last IP packet e. Thus, in this case, the sender node does not compress the RTP/UDP/IP headers of this IP packet and transmits a full-header packet g having a full header in which the lengths in the RTP/UDP/IP headers of the packet g is replaced by the CONTEXT_ID and link_seq. The receiver node that received this full-header packet g converts the full header into the RTP/UDP/IP headers and memorizes them in the internal storage.
The header compression method ruled by the RFC2508 has been described above (hereinafter referred to as a “method A”). However, this compression method has been suffering from some drawbacks, which will be described as follows.
For instance, as shown in FIG. 15, an assumption is made that the header-compressed packet c is lost between the transmitter and receiver nodes for some reason. As described above, when decompressing the packet d, the receiver node adds the difference value ΔB to the delta fields B of the IP packet c to decompress the delta fields B of the IP packet d. As a result, when the header-compressed packet c is lost, it is impossible to decompress the delta fields B of the header-compressed packet d. The receiver node is therefore forced to discard packets d, e and f shown in FIG. 15, which are received until the next full-header packet g. In other words, the loss of the packets causes consecutive losses of some other packets, which leads to reducing a throughput compared to a method in which the header compression is not involved. In particular, in cases the transmitter and receiver nodes are connected by a wireless link, a packet is likely to be lost in the wireless link. If such a loss occurs, some other packets are frequently discarded at the receiver node. As a technique to resolve such a problem, the RFC 2507 and 2508 issued by the IETF and the Internet-Draft provide the following methods.
Method 1: Repetitive Transmission of Full-header Packet (RFC 2507)
In the case of the foregoing conventional method A, the sender node transmits a full-header packet only when the static fields of a header change in value. In contrast, as shown in FIG. 16, this method 1 selects several IP packets to be transmitted every predetermined number of packets, regardless of whether the static fields changes in value or not. And the selected IP packets are converted to the full header packets with full headers and the full header packets are transmitted to the receiver node, while the remaining IP packets are converted to header-compressed packet with compressed headers and the header-compressed packets are transmitted to the receiver node. In the method A, since full-header packets are not transmitted to the receiver node as long as their static fields do not change in value, all the packets transmitted after the occurrence of loss of a packet are discarded. In contrast, the present method 1 allows a full-header packet to be transmitted at intervals, so that it has the advantage that the number of packets discarded owing to the loss of the packets can be lowered. However, the present method 1 has trade-offs that a longer period for transmitting full-header packets results in that the number of packets discarded is raised, whilst a shorter period for transmitting full-header packets results in that a large number of full-header packets with large overheads are transmitted, reducing efficiency in communication.
Method 2: Request for Full Headers Through Back Channel (RFC2507 and 2508)
As shown in FIG. 17, when detecting the loss of a packet, the present method 2 permits the receiver node to transmit a CONTEXT_STATE, a message to request a full-header packet for the sender node. When receiving the CONTEXT_STATE, the sender node transmits the next IP packet to the receiver node in the form of a full-header packet. As a result, an interval during which some packets are discarded due to the loss of a certain packet can be limited to the interval starting between the occurrence and the packet loss to the reception of a full-header packet transmitted in response to the CONTEXT_STATE. Nevertheless, the present method has a drawback that as the interval between the transmission of the CONTEXT_STATE and the reception of a full-header packet at the receiver node, that is, an RTT (Round Trip Time), becomes larger, the number of packets discarded are also raised. For communicating packets by way of a wireless link, such a drawback becomes noticeable, because the RTT of the wireless link is very long.
Method 3: Twice Algorithm (RFC 2507)
According to the present method 3, the compressed headers of header-compressed packets received after the loss of a certain packet are decompressed using the RTP/UDP/IP headers decompressed most lately before the occurrence of loss of the packet. For example, as shown in FIG. 18, it is assumed that after a packet b is received in order, a packet c is lost, and then a packet d is received in order. In this situation, when a difference value ΔB is unchanged in value over the packets b to d, the delta fields B of the packet d can be calculated by adding a value of double ΔB to the delta fields B of the packet b. Moreover, the present method needs the UDP checksum included in a compressed header (refer to FIG. 13B), so that the UDP checksum is used to determine if packets were decompressed correctly. However, as shown in FIG. 18, in cases where a packet k is lost and difference values ΔB of the delta fields between packets and k change, there is the problem that a packet 1 received immediately after the packet loss cannot be decompressed correctly. In particular, in the case that packets are communicated via a wireless link, there is a possibility that packets are lost in sequence (namely, over a long interval). Under such a situation, it is considered that difference values ΔB are likely to change for a large number of lost packets. Therefore the foregoing problem is amplified.
Method 4, ROCCO (Internet-Draft)
According to the present method 4, the difference value ΔB can be estimated on a characteristic of a media through which packets are transmitted. For example, in the case of FIG. 19, it is assumed that packets g and b are lost and difference values ΔB between the packets g and h change. In this case, changes in the difference values ΔB are estimated on a characteristic of a media through which packets are transmitted, and a packet can be decompressed through addition of the estimated difference value ΔB to the packet f. Additionally, the present method uses an error detecting code (CRC) to confirm if the decompression is performed correctly or not. Thus, even if the difference value ΔB changes, the present method enables packets received after the loss of a certain packet to be decompressed. However, the present method involves a difficulty in how the difference value ΔB is estimated.
As described above, although a variety of techniques have been proposed to efficiently perform data communication even when RTP/UDP/IP headers of IP packets are compressed, any technique has some drawbacks. Thus, it is a present situation that there is a limitation in effectively reducing the number of packets to be discarded owing to the loss of a certain packet that has been caused between the transmitter and receiver nodes. That is to say, loss of a part of packets during the packet transmission between the transmitter and the receiver nodes causes loss of the other packets in the receiver node. This causes great damage on the data processing using the packets received by the receiver data terminal (for example, display of image or replay of music using the received packets).